CentOS 7 (OpenVZ): сеть не поднимается после перезагрузки — [fix]
Ситуация, когда после перезагрузки в контейнере CentOS 7 (OpenVZ) “пропадает сеть”, встречается достаточно часто: интерфейс не поднимается, маршрутов нет, DNS не работает, а удалённый доступ теряется. Это может случиться после обновлений, смены шаблона, миграции на другой узел или изменения режима виртуального интерфейса на стороне хоста. Ниже — практическая инструкция: как вернуть доступ, понять причину и сделать так, чтобы после следующего reboot всё снова поднялось автоматически.
Если у вас продакшен-нагрузки и вам нужна предсказуемая сеть после перезапуска, имеет смысл задуматься и о платформе. Для более современного изоляционного подхода и гибких сетевых настроек часто выбирают VPS. Для гарантированных ресурсов и полного контроля есть выделенные серверы. А если вам не нужна кастомная ОС-настройка и достаточно стандартной среды, может подойти хостинг.
Ключевой принцип: сначала получите доступ через консоль (панель провайдера/контейнерная консоль), затем диагностируйте. У OpenVZ есть нюансы: часть сетевого поведения задаётся хостом, и контейнер не всегда ведёт себя как полноценная VM. Поэтому “фикс” обычно сводится к тому, чтобы согласовать ifcfg-конфиги CentOS с реальным именем интерфейса и не смешивать разные системы управления сетью.
1) Быстрая диагностика: есть ли интерфейс и какой у него статус
Подключитесь через консоль и выполните “ip a”, “ip link”, “ip r”. В OpenVZ вы можете увидеть eth0, venet0 или veth0 — это зависит от конфигурации. Если интерфейс существует, но DOWN, возможно, сервис сети не поднимает его после reboot или ONBOOT отключён. Если IP отсутствует, проблема может быть в ifcfg или в конфликте с NetworkManager.
Проверьте статус и логи: “systemctl status network” и “journalctl -u network -b”. Ошибки вида “device not found” обычно означают, что в ifcfg указан DEVICE, который не совпадает с реальным интерфейсом (например, ifcfg-eth0, а внутри контейнера теперь venet0). Это одна из самых частых причин, почему сеть не стартует после перезагрузки.
Также сразу проверьте наличие default route. Даже при наличии IP без маршрута по умолчанию вы не выйдете в интернет. Команда “ip r” должна показать маршрут default через gateway. Если его нет — проверьте GATEWAY и данные, которые выдаёт провайдер.
2) Классический фикс: поправить ifcfg и перезапустить network
В CentOS 7 конфиги сети обычно лежат в /etc/sysconfig/network-scripts/. Найдите файл ifcfg для вашего интерфейса и проверьте параметры: DEVICE, BOOTPROTO, ONBOOT, IPADDR, NETMASK или PREFIX, GATEWAY, DNS1/DNS2. Для автозапуска после reboot критично ONBOOT=yes.
Если адрес статический, убедитесь, что IPADDR и GATEWAY корректны. В OpenVZ gateway часто задаётся провайдером. Если вы выставили неверный gateway, интерфейс может подняться, но наружу ничего не пойдёт. Поэтому после изменений обязательно смотрите “ip r”.
# пример: /etc/sysconfig/network-scripts/ifcfg-eth0 TYPE=Ethernet DEVICE=eth0 ONBOOT=yes BOOTPROTO=static IPADDR=203.0.113.10 PREFIX=24 GATEWAY=203.0.113.1 DNS1=1.1.1.1 DNS2=8.8.8.8
После правок выполните “systemctl restart network” и снова проверьте “ip a” и “ip r”. Если доступно, можно использовать “ifdown eth0; ifup eth0”. В OpenVZ тип интерфейса может быть нестандартным, но network-scripts часто работают, если DEVICE совпадает с реальным именем.
Если вы пытались DHCP, проверьте, поддерживает ли провайдер DHCP именно в этом контейнере. Во многих серверных конфигурациях используются статические IP. Если DHCP не доступен, сеть может “висеть” в ожидании lease, и после reboot вы останетесь без подключения.
3) Конфликт с NetworkManager: выбираем один способ управления
CentOS 7 нередко поставляется с NetworkManager. На серверах, а особенно в контейнерах OpenVZ, он может конфликтовать с классическим сервисом “network”. Если NetworkManager “забирает” интерфейс, он может игнорировать ifcfg или применять другой профиль после reboot.
Если “network” показывает успех, но IP не появился, проверьте “systemctl status NetworkManager”. При необходимости отключите NetworkManager и оставьте только network-scripts. Делайте это осторожно и только с консольным доступом, потому что неправильный шаг может оборвать последнюю сессию.
4) DNS-проблемы, которые выглядят как “нет сети”
Иногда IP и маршрутизация в порядке, но не работает DNS. Проверка простая: “ping 8.8.8.8” и “ping google.com”. Если по IP пингуется, а домен — нет, значит проблема в /etc/resolv.conf или DNS1/DNS2 в ifcfg. В OpenVZ resolv.conf иногда перезаписывается, поэтому важно, чтобы DNS был задан так, чтобы он сохранялся после reboot.
Плюс проверьте firewall. Иногда после обновлений firewalld/iptables начинает фильтровать трафик иначе, и кажется, что “сеть умерла”. Посмотрите “systemctl status firewalld” и правила, если вы недавно меняли пакеты безопасности.
5) Специфика OpenVZ: venet/veth и изменения на стороне хоста
OpenVZ может работать через venet (маршрутизируемый интерфейс без L2) или veth (виртуальный Ethernet). Если на стороне хоста поменяли режим, в контейнере могут измениться имя интерфейса и поведение. Поэтому после reboot сравните “ip link” и DEVICE в ifcfg. Несовпадение — самый частый корень проблемы.
Иногда IP/маршруты “пушатся” с хоста, и в контейнере нельзя нормально закрепить адрес. Тогда проверяйте панель провайдера и настройки контейнера на стороне хоста. В такой ситуации лучше вернуться к минимальной совместимой конфигурации, которая не конфликтует с host-managed параметрами.
Проверка после исправления и профилактика
После фикса проверьте по чек-листу: (1) “ip a” — есть IP; (2) “ip r” — есть default route; (3) ping gateway; (4) ping публичный IP; (5) ping домен (DNS); (6) сделайте ещё одну перезагрузку и убедитесь, что всё поднялось автоматически. Вторая перезагрузка — лучший тест устойчивости решения.
Для профилактики держите конфиги сети простыми, не смешивайте NetworkManager и network-scripts, и перед крупными обновлениями сохраняйте копию рабочих ifcfg. Если вам регулярно нужен предсказуемый сетевой стек после reboot и больше контроля, рассмотрите миграцию на VM/VPS, где сеть полностью управляется внутри ОС, а не частично ограничена контейнерной виртуализацией.